System and Method for Distributed Management of Shared Computers

ABSTRACT

A multi-tiered server management architecture is employed including an application development tier, an application operations tier, and a cluster operations tier. In the application development tier, applications are developed for execution on one or more server computers. In the application operations tier, execution of the applications is managed and sub-boundaries within a cluster of servers can be established. In the cluster operations tier, operation of the server computers is managed without concern for what applications are executing on the one or more server computers and boundaries between clusters of servers can be established. The multi-tiered server management architecture can also be employed in co-location facilities where clusters of servers are leased to tenants, with the tenants implementing the application operations tier and the facility owner (or operator) implementing the cluster operations tier.

RELATED APPLICATIONS

This application is a continuation application of U.S. patentapplication Ser. No. 10/987,229, filed Nov. 12, 2004, which is herebyincorporated by reference herein, and which is a divisional applicationof U.S. Patent Application Ser. No. 09/695,812, filed Oct. 24, 2000,entitled “System and Method for Distributed Management of SharedComputers”, which is hereby incorporated by reference herein.

TECHNICAL FIELD

This invention relates to computer system management. More particularly,the invention relates to the distributed management of shared computers.

BACKGROUND OF THE INVENTION

The Internet and its use have expanded greatly in recent years, and thisexpansion is expected to continue. One significant way in which theInternet is used is the World Wide Web (also referred to as the “web”),which is a collection of documents (referred to as “web pages”) thatusers can view or otherwise render and which typically include links toone or more other pages that the user can access. Many businesses andindividuals have created a presence on the web, typically consisting ofone or more web pages describing themselves, describing their productsor services, identifying other information of interest, allowing goodsor services to be purchased, etc.

Web pages are typically made available on the web via one or more webservers, a process referred to as “hosting” the web pages. Sometimesthese web pages are freely available to anyone that requests to viewthem (e.g., a company's advertisements) and other times access to theweb pages is restricted (e.g., a password may be necessary to access theweb pages). Given the large number of people that may be requesting toview the web pages (especially in light of the global accessibility tothe web), a large number of servers may be necessary to adequately hostthe web pages (e.g., the same web page can be hosted on multiple serversto increase the number of people that can access the web pageconcurrently). Additionally, because the web is geographicallydistributed and has non-uniformity of access, it is often desirable todistribute servers to diverse remote locations in order to minimizeaccess times for people in diverse locations of the world. Furthermore,people tend to view web pages around the clock (again, especially inlight of the global accessibility to the web), so servers hosting webpages should be kept functional 24 hours per day.

Managing a large number of servers, however, can be difficult. Areliable power supply is necessary to ensure the servers can run.Physical security is necessary to ensure that a thief or othermischievous person does not attempt to damage or steal the servers. Areliable Internet connection is required to ensure that the accessrequests will reach the servers. A proper operating environment (e.g.,temperature, humidity, etc.) is required to ensure that the serversoperate properly. Thus, “co-location facilities” have evolved whichassist companies in handling these difficulties.

A co-location facility refers to a complex that can house multipleservers. The co-location facility typically provides a reliable Internetconnection, a reliable power supply, and proper operating environment.The co-location facility also typically includes multiple secure areas(e.g., cages) into which different companies can situate their servers.The collection of servers that a particular company situates at theco-location facility is referred to as a “server cluster”, even thoughin fact there may only be a single server at any individual co-locationfacility. The particular company is then responsible for managing theoperation of the servers in their server cluster.

Such co-location facilities, however, also present problems. One problemis data security. Different companies (even competitors) can have serverclusters at the same co-location facility. Care is required, in suchcircumstances, to ensure that data received from the Internet (or sentby a server in the server cluster) that is intended for one company isnot routed to a server of another company situated at the co-locationfacility.

An additional problem is the management of the servers once they areplaced in the co-location facility. Currently, a system administratorfrom a company is able to contact a co-location facility administrator(typically by telephone) and ask him or her to reset a particular server(typically by pressing a hardware reset button on the server, orpowering off then powering on the server) in the event of a failure of(or other problem with) the server. This limited reset-only abilityprovides very little management functionality to the company.Alternatively, the system administrator from the company can physicallytravel to the co-location facility him/her-self and attend to the faultyserver. Unfortunately, a significant amount of time can be wasted by thesystem administrator in traveling to the co-location facility to attendto a server. Thus, it would be beneficial to have an improved way tomanage remote server computers at a co-location facility.

Another problem concerns the enforcement of the rights of both theoperators of the servers in the co-location facility and the operatorsof the web service hosted on those servers. The operators of the serversneed to be able to maintain their rights (e.g., re-possessing areas ofthe facility where servers are stored), even though the servers areowned by the operators of the web service. Additionally, the operatorsof the web service need to be assured that their data remains secure.

The invention described below addresses these disadvantages, improvingthe distributed management of shared computers in co-locationfacilities.

SUMMARY OF THE INVENTION

Distributed management of shared computers is described herein.

According to one aspect, a multi-tiered management architecture isemployed including an application development tier, an applicationoperations tier, and a cluster operations tier. In the applicationdevelopment tier, applications are developed for execution on one ormore server computers. In the application operations tier, execution ofthe applications is managed and sub-boundaries within a cluster ofservers at a co-location facility may be established. In the clusteroperations tier, operation of the server computers is managed withoutconcern for what applications are executing on the one or more servercomputers, and server cluster boundaries at the co-location facility maybe established.

According to another aspect, a co-location facility includes multipleserver clusters, each corresponding to a different customer. For eachserver cluster, a cluster operations management console is implementedlocally at the co-location facility to manage hardware operations of thecluster, and an application operations management console is implementedat a location remote from the co-location facility to manage softwareoperations of the cluster. In the event of a hardware failure, thecluster operations management console takes corrective action (e.g.,notifying an administrator at the co-location facility or attempting tocorrect the failure itself). In the event of a software failure, theapplication operations management console takes corrective action (e.g.,notifying one of the customer's administrators or attempting to correctthe failure itself).

According to another aspect, boundaries of a server cluster areestablished by a cluster operations management console. Establishment ofthe boundaries ensures that data is routed only to nodes within theserver cluster, and not to other nodes at the co-location facility thatare not part of the server cluster. Further sub-boundaries within aserver cluster may be established by an application operationsmanagement console to ensure data is routed only to particular nodeswithin the server cluster.

According to another aspect, rights to multiple server computers to belocated at a co-location facility are sold to a customer and amultiple-tiered management scheme is enforced on the server computers.According to the multiple-tiered management scheme, hardware operationof the server computers is managed locally at the co-location facilitywhereas software operation of the server computers is managed from alocation remote from the co-location facility. The server computers canbe either sold to the customer or leased to the customer.

According to another aspect, a landlord/tenant relationship is createdusing one or more server computers at a co-location facility. Theoperator of the co-location facility supplies the facility as well asthe servers (and thus can be viewed as a “landlord”), while customers ofthe facility lease the use of the facility as well as servers at thatfacility (and thus can be viewed as “tenants”). This landlord/tenantrelationship allows the landlord to establish clusters of computers fordifferent tenants and establish boundaries between clusters so that atenant's data does not pass beyond its cluster (and to another tenant'scluster). Additionally, encryption is employed in various manners toassure the tenant that information stored at the servers it leasescannot be viewed by anyone else, even if the tenant terminates its leaseor returns to the landlord one of the servers it is leasing.

According to another aspect, a multi-tiered management architecture isemployed in managing computers that are not part of a co-locationfacility. This multi-tiered architecture is used for managing computers(whether server computers or otherwise) in a variety of settings, suchas businesses, homes, etc.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and notlimitation in the figures of the accompanying drawings. The same numbersare used throughout the figures to reference like components and/orfeatures.

FIG. 1 shows a client/server network system and environment such as maybe used with certain embodiments of the invention.

FIG. 2 shows a general example of a computer that can be used inaccordance with certain embodiments of the invention.

FIG. 3 is a block diagram illustrating an exemplary co-location facilityin more detail.

FIG. 4 is a block diagram illustrating an exemplary multi-tieredmanagement architecture.

FIG. 5 is a block diagram illustrating an exemplary node in more detailin accordance with certain embodiments of the invention.

FIG. 6 is a flowchart illustrating an exemplary process for encryptionkey generation and distribution in accordance with certain embodimentsof the invention.

FIG. 7 is a flowchart illustrating an exemplary process for theoperation of a cluster operations management console in accordance withcertain embodiments of the invention.

FIG. 8 is a flowchart illustrating an exemplary process for theoperation of an application operations management console in accordancewith certain embodiments of the invention.

DETAILED DESCRIPTION

FIG. 1 shows a client/server network system and environment such as maybe used with certain embodiments of the invention. Generally, the systemincludes multiple (n) client computers 102 and multiple (m) co-locationfacilities 104 each including multiple clusters of server computers(server clusters) 106. The servers and client computers communicate witheach other over a data communications network 108. The communicationsnetwork in FIG. 1 comprises a public network 108 such as the Internet.Other types of communications networks might also be used, in additionto or in place of the Internet, including local area networks (LANs),wide area networks (WANs), etc. Data communications network 108 can beimplemented in any of a variety of different manners, including wiredand/or wireless communications media.

Communication over network 108 can be carried out using any of a widevariety of communications protocols. In one implementation, clientcomputers 102 and server computers in clusters 106 can communicate withone another using the Hypertext Transfer Protocol (HTTP), in which webpages are hosted by the server computers and written in a markuplanguage, such as the Hypertext Markup Language (HTML) or the eXtensibleMarkup Language (XML).

In the discussions herein, embodiments of the invention are describedprimarily with reference to implementation at a co-location facility(such as facility 104). The invention, however, is not limited to suchimplementations and can be used for distributed management in any of awide variety of situations. For example, in situations where all of theservers at a facility are owned or leased to the same customer, insituations where a single computing device (e.g., a server or client) isbeing managed, in situations where computers (whether servers orotherwise) in a business or home environment are being managed, etc.

In the discussion herein, embodiments of the invention are described inthe general context of computer-executable instructions, such as programmodules, being executed by one or more conventional personal computers.Generally, program modules include routines, programs, objects,components, data structures, etc. that perform particular tasks orimplement particular abstract data types. Moreover, those skilled in theart will appreciate that various embodiments of the invention may bepracticed with other computer system configurations, including hand-helddevices, gaming consoles, Internet appliances, multiprocessor systems,microprocessor-based or programmable consumer electronics, network PCs,minicomputers, mainframe computers, and the like. In a distributedcomputer environment, program modules may be located in both local andremote memory storage devices.

Alternatively, embodiments of the invention can be implemented inhardware or a combination of hardware, software, and/or firmware. Forexample, all or part of the invention can be implemented in one or moreapplication specific integrated circuits (ASICs) or programmable logicdevices (PLDs).

FIG. 2 shows a general example of a computer 142 that can be used inaccordance with certain embodiments of the invention. Computer 142 isshown as an example of a computer that can perform the functions of aclient computer 102 of FIG. 1, a computer or node in a co-locationfacility 104 of FIG. 1 or other location (e.g., node 248 of FIG. 5below), or a local or remote management console as discussed in moredetail below.

Computer 142 includes one or more processors or processing units 144, asystem memory 146, and a bus 148 that couples various system componentsincluding the system memory 146 to processors 144. The bus 148represents one or more of any of several types of bus structures,including a memory bus or memory controller, a peripheral bus, anaccelerated graphics port, and a processor or local bus using any of avariety of bus architectures. The system memory includes read onlymemory (ROM) 150 and random access memory (RAM) 152. A basicinput/output system (BIOS) 154, containing the basic routines that helpto transfer information between elements within computer 142, such asduring start-up, is stored in ROM 150.

Computer 142 further includes a hard disk drive 156 for reading from andwriting to a hard disk, not shown, connected to bus 148 via a hard diskdriver interface 157 (e.g., a SCSI, ATA, or other type of interface); amagnetic disk drive 158 for reading from and writing to a removablemagnetic disk 160, connected to bus 148 via a magnetic disk driveinterface 161; and an optical disk drive 162 for reading from or writingto a removable optical disk 164 such as a CD ROM, DVD, or other opticalmedia, connected to bus 148 via an optical drive interface 165. Thedrives and their associated computer-readable media provide nonvolatilestorage of computer readable instructions, data structures, programmodules and other data for computer 142. Although the exemplaryenvironment described herein employs a hard disk, a removable magneticdisk 160 and a removable optical disk 164, it should be appreciated bythose skilled in the art that other types of computer readable mediawhich can store data that is accessible by a computer, such as magneticcassettes, flash memory cards, digital video disks, random accessmemories (RAMs) read only memories (ROM), and the like, may also be usedin the exemplary operating environment.

A number of program modules may be stored on the hard disk, magneticdisk 160, optical disk 164, ROM 150, or RAM 152, including an operatingsystem 170, one or more application programs 172, other program modules174, and program data 176. A user may enter commands and informationinto computer 142 through input devices such as keyboard 178 andpointing device 180. Other input devices (not shown) may include amicrophone, joystick, game pad, satellite dish, scanner, or the like.These and other input devices are connected to the processing unit 144through an interface 168 that is coupled to the system bus. A monitor184 or other type of display device is also connected to the system bus148 via an interface, such as a video adapter 186. In addition to themonitor, personal computers typically include other peripheral outputdevices (not shown) such as speakers and printers.

Computer 142 optionally operates in a networked environment usinglogical connections to one or more remote computers, such as a remotecomputer 188. The remote computer 188 may be another personal computer,a server, a router, a network PC, a peer device or other common networknode, and typically includes many or all of the elements described aboverelative to computer 142, although only a memory storage device 190 hasbeen illustrated in FIG. 2. The logical connections depicted in FIG. 2include a local area network (LAN) 192 and a wide area network (WAN)194. Such networking environments are commonplace in offices,enterprise-wide computer networks, intranets, and the Internet. In thedescribed embodiment of the invention, remote computer 188 executes anInternet Web browser program (which may optionally be integrated intothe operating system 170) such as the “Internet Explorer” Web browsermanufactured and distributed by Microsoft Corporation of Redmond,Washington.

When used in a LAN networking environment, computer 142 is connected tothe local network 192 through a network interface or adapter 196. Whenused in a WAN networking environment, computer 142 typically includes amodem 198 or other component for establishing communications over thewide area network 194, such as the Internet. The modem 198, which may beinternal or external, is connected to the system bus 148 via aninterface (e.g., a serial port interface 168). In a networkedenvironment, program modules depicted relative to the personal computer142, or portions thereof, may be stored in the remote memory storagedevice. It is to be appreciated that the network connections shown areexemplary and other means of establishing a communications link betweenthe computers may be used.

Generally, the data processors of computer 142 are programmed by meansof instructions stored at different times in the variouscomputer-readable storage media of the computer. Programs and operatingsystems are typically distributed, for example, on floppy disks orCD-ROMs. From there, they are installed or loaded into the secondarymemory of a computer. At execution, they are loaded at least partiallyinto the computer's primary electronic memory. The invention describedherein includes these and other various types of computer-readablestorage media when such media contain instructions or programs forimplementing the steps described below in conjunction with amicroprocessor or other data processor. The invention also includes thecomputer itself when programmed according to the methods and techniquesdescribed below. Furthermore, certain sub-components of the computer maybe programmed to perform the functions and steps described below. Theinvention includes such sub-components when they are programmed asdescribed. In addition, the invention described herein includes datastructures, described below, as embodied on various types of memorymedia.

For purposes of illustration, programs and other executable programcomponents such as the operating system are illustrated herein asdiscrete blocks, although it is recognized that such programs andcomponents reside at various times in different storage components ofthe computer, and are executed by the data processor(s) of the computer.

FIG. 3 is a block diagram illustrating an exemplary co-location facilityin more detail. Co-location facility 104 is illustrated includingmultiple nodes (also referred to as server computers) 210. Co-locationfacility 104 can include any number of nodes 210, and can easily includean amount of nodes numbering into the thousands.

The nodes 210 are grouped together in clusters, referred to as serverclusters (or node clusters). For ease of explanation and to avoidcluttering the drawings, only a single cluster 212 is illustrated inFIG. 3. Each server cluster includes nodes 210 that correspond to aparticular customer of co-location facility 104. The nodes 210 of aserver cluster are physically isolated from the nodes 210 of otherserver clusters. This physical isolation can take different forms, suchas separate locked cages or separate rooms at co-location facility 104.Physically isolating server clusters ensures customers of co-locationfacility 104 that only they can physically access their nodes (othercustomers cannot). Alternatively, server clusters may be logically, butnot physically, isolated for each other (e.g., using cluster boundariesas discussed in more detail below).

A landlord/tenant relationship (also referred to as a lessor/lesseerelationship) can also be established based on the nodes 210. The owner(and/or operator) of co-location facility 104 owns (or otherwise hasrights to) the individual nodes 210, and thus can be viewed as a“landlord”. The customers of co-location facility 104 lease the nodes210 from the landlord, and thus can be viewed as a “tenant”. Thelandlord is typically not concerned with what types of data or programsare being stored at the nodes 210 by the tenant, but does imposeboundaries on the clusters that prevent nodes 210 from differentclusters from communicating with one another, as discussed in moredetail below.

The landlord/tenant relationship is discussed herein primarily withreference to only two levels: the landlord and the tenant. However, inalternate embodiments this relationship can be expanded to any number oflevels. For example, the landlord may share its managementresponsibilities with one or more sub-landlords (each of which wouldhave certain managerial control over one or more nodes 210), and thetenant may similarly share its management responsibilities with one ormore sub-tenants (each of which would have certain managerial controlover one or more nodes 210).

Although physically isolated, nodes 210 of different clusters are oftenphysically coupled to the same transport medium (or media) 211 thatenables access to network connection(s) 216, and possibly applicationoperations management console 242, discussed in more detail below. Thistransport medium can be wired or wireless.

As each node 210 can be coupled to a shared transport medium 211, eachnode 210 is configurable to restrict which other nodes 210 data can besent to or received from. Given that a number of different nodes 210 maybe included in a tenant's server cluster, the tenant may want to be ableto pass data between different nodes 210 within the cluster forprocessing, storage, etc. However, the tenant will typically not wantdata to be passed to other nodes 210 that are not in the server cluster.Configuring each node 210 in the cluster to restrict which other nodes210 data can be sent to or received from allows a boundary for theserver cluster to be established and enforced. Establishment andenforcement of such server cluster boundaries prevents tenant data frombeing erroneously or improperly forwarded to a node that is not part ofthe cluster.

These initial boundaries established by the landlord preventcommunication between nodes 210 of different tenants, thereby ensuringthat each tenant's data can be passed to other nodes 210 of that tenant.The tenant itself may also further define sub-boundaries within itscluster, establishing sub-clusters of nodes 210 that data cannot becommunicated out of (or in to) either to or from other nodes in thecluster. The tenant is able to add, modify, remove, etc. suchsub-cluster boundaries at will, but only within the boundaries definedby the landlord (that is, the cluster boundaries). Thus, the tenant isnot able to alter boundaries in a manner that would allow communicationto or from a node 210 to extend to another node 210 that is not withinthe same cluster.

Co-location facility 104 supplies reliable power 214 and reliablenetwork connection(s) 216 to each of the nodes 210. Power 214 andnetwork connection(s) 216 are shared by all of the nodes 210, althoughalternatively separate power 214 and network connection(s) 216 may besupplied to nodes 210 or groupings (e.g., clusters) of nodes. Any of awide variety of conventional mechanisms for supplying reliable power canbe used to supply reliable power 214, such as power received from apublic utility company along with backup generators in the event ofpower failures, redundant generators, batteries, fuel cells, or otherpower storage mechanisms, etc. Similarly, any of a wide variety ofconventional mechanisms for supplying a reliable network connection canbe used to supply network connection(s) 216, such as redundantconnection transport media, different types of connection media,different access points (e.g., different Internet access points,different Internet service providers (ISPs), etc.).

In certain embodiments, nodes 210 are leased or sold to customers by theoperator or owner of co-location facility 104 along with the space(e.g., locked cages) and service (e.g., access to reliable power 214 andnetwork connection(s) 216) at facility 104. In other embodiments, spaceand service at facility 104 may be leased to customers while one or morenodes are supplied by the customer.

Management of each node 210 is carried out in a multiple-tiered manner.FIG. 4 is a block diagram illustrating an exemplary multi-tieredmanagement architecture. The multi-tiered architecture includes threetiers: a cluster operations management tier 230, an applicationoperations management tier 232, and an application development tier 234.Cluster operations management tier 230 is implemented locally at thesame location as the server(s) being managed (e.g., at a co-locationfacility) and involves managing the hardware operations of theserver(s). In the illustrated example, cluster operations managementtier 230 is not concerned with what software components are executing onthe nodes 210, but only with the continuing operation of the hardware ofnodes 210 and establishing any boundaries between clusters of nodes.

The application operations management tier 232, on the other hand, isimplemented at a remote location other than where the server(s) beingmanaged are located (e.g., other than the co-location facility), butfrom a client computer that is still communicatively coupled to theserver(s). The application operations management tier 232 involvesmanaging the software operations of the server(s) and definingsub-boundaries within server clusters. The client can be coupled to theserver(s) in any of a variety of manners, such as via the Internet orvia a dedicated (e.g., dial-up) connection. The client can be coupledcontinually to the server(s), or alternatively sporadically (e.g., onlywhen needed for management purposes).

The application development tier 234 is implemented on another clientcomputer at a location other than the server(s) (e.g., other than at theco-location facility) and involves development of software components orengines for execution on the server(s). Alternatively, current softwareon a node 210 at co-location facility 104 could be accessed by a remoteclient to develop additional software components or engines for thenode. Although the client at which application development tier 234 isimplemented is typically a different client than that at whichapplication operations management tier 232 is implemented, tiers 232 and234 could be implemented (at least in part) on the same client.

Although only three tiers are illustrated in FIG. 4, alternatively themulti-tiered architecture could include different numbers of tiers. Forexample, the application operations management tier may be separatedinto two tiers, each having different (or overlapping) responsibilities,resulting in a 4-tiered architecture. The management at these tiers mayoccur from the same place (e.g., a single application operationsmanagement console may be shared), or alternatively from differentplaces (e.g., two different operations management consoles).

Returning to FIG. 3, co-location facility 104 includes a clusteroperations management console for each server cluster. In the example ofFIG. 3, cluster operations management console 240 corresponds to cluster212. Cluster operations management console 240 implements clusteroperations management tier 230 (FIG. 4) for cluster 212 and isresponsible for managing the hardware operations of nodes 210 in cluster212. Cluster operations management console 240 monitors the hardware incluster 212 and attempts to identify hardware failures. Any of a widevariety of hardware failures can be monitored for, such as processorfailures, bus failures, memory failures, etc. Hardware operations can bemonitored in any of a variety of manners, such as cluster operationsmanagement console 240 sending test messages or control signals to thenodes 210 that require the use of particular hardware in order torespond (no response or an incorrect response indicates failure), havingmessages or control signals that require the use of particular hardwareto generate periodically sent by nodes 210 to cluster operationsmanagement console 240 (not receiving such a message or control signalwithin a specified amount of time indicates failure), etc.Alternatively, cluster operations management console 240 may make noattempt to identify what type of hardware failure has occurred, butrather simply that a failure has occurred.

Once a hardware failure is detected, cluster operations managementconsole 240 acts to correct the failure. The action taken by clusteroperations management console 240 can vary based on the hardware as wellas the type of failure, and can vary for different server clusters. Thecorrective action can be notification of an administrator (e.g., aflashing light, an audio alarm, an electronic mail message, calling acell phone or pager, etc.), or an attempt to physically correct theproblem (e.g., reboot the node, activate another backup node to take itsplace, etc.).

Cluster operations management console 240 also establishes clusterboundaries within co-location facility 104. The cluster boundariesestablished by console 240 prevent nodes 210 in one cluster (e.g.,cluster 212) from communicating with nodes in another cluster (e.g., anynode not in cluster 212), while at the same time not interfering withthe ability of nodes 210 within a cluster from communicating with othernodes within that cluster. These boundaries provide security for thetenants' data, allowing them to know that their data cannot becommunicated to other tenants' nodes 210 at facility 104 even thoughnetwork connection 216 may be shared by the tenants.

In the illustrated example, each cluster of co-location facility 104includes a dedicated cluster operations management console.Alternatively, a single cluster operations management console maycorrespond to, and manage hardware operations of, multiple serverclusters. According to another alternative, multiple cluster operationsmanagement consoles may correspond to, and manage hardware operationsof, a single server cluster. Such multiple consoles can manage a singleserver cluster in a shared manner, or one console may operate as abackup for another console (e.g., providing increased reliabilitythrough redundancy, to allow for maintenance, etc.).

An application operations management console 242 is also communicativelycoupled to co-location facility 104. Application operations managementconsole 242 is located at a location remote from co-location facility104 (that is, not within co-location facility 104), typically beinglocated at the offices of the customer. A different applicationoperations management console 242 corresponds to each server cluster ofco-location facility 104, although alternatively multiple consoles 242may correspond to a single server cluster, or a single console 242 maycorrespond to multiple server clusters. Application operationsmanagement console 242 implements application operations management tier232 (FIG. 4) for cluster 212 and is responsible for managing thesoftware operations of nodes 210 in cluster 212 as well as securingsub-boundaries within cluster 212.

Application operations management console 242 monitors the software incluster 212 and attempts to identify software failures. Any of a widevariety of software failures can be monitored for, such as applicationprocesses or threads that are “hung” or otherwise non-responsive, anerror in execution of application processes or threads, etc. Softwareoperations can be monitored in any of a variety of manners (similar tothe monitoring of hardware operations discussed above), such asapplication operations management console 242 sending test messages orcontrol signals to particular processes or threads executing on thenodes 210 that require the use of particular routines in order torespond (no response or an incorrect response indicates failure), havingmessages or control signals that require the use of particular softwareroutines to generate periodically sent by processes or threads executingon nodes 210 to application operations management console 242 (notreceiving such a message or control signal within a specified amount oftime indicates failure), etc. Alternatively, application operationsmanagement console 242 may make no attempt to identify what type ofsoftware failure has occurred, but rather simply that a failure hasoccurred.

Once a software failure is detected, application operations managementconsole 242 acts to correct the failure. The action taken by applicationoperations management console 242 can vary based on the hardware as wellas the type of failure, and can vary for different server clusters. Thecorrective action can be notification of an administrator (e.g., aflashing light, an audio alarm, an electronic mail message, calling acell phone or pager, etc.), or an attempt to correct the problem (e.g.,reboot the node, re-load the software component or engine image,terminate and re-execute the process, etc.).

Thus, the management of a node 210 is distributed across multiplemanagers, regardless of the number of other nodes (if any) situated atthe same location as the node 210. The multi-tiered management allowsthe hardware operations management to be separated from the applicationoperations management, allowing two different consoles (each under thecontrol of a different entity) to share the management responsibilityfor the node.

The multi-tiered management architecture can also be used in othersituations to manage one or more computers from one or more remotelocations, even if the computers are not part of a co-location facility.By way of example, a small business may purchase their own computers,but hire another company to manage the hardware operations of thecomputers, and possibly yet another company to manage the softwareoperations of the computers.

In this example, the small business (the owner of the computers) is afirst management tier. The owner then leases the computers to theoutsourced hardware operator, which is the second management tier. Thehardware operator can manage the hardware operation from a controlconsole, either located locally at the small business along with thecomputers being managed or alternatively at some remote location,analogous to cluster operations management console 240. The hardwareoperator then leases the computers to an outsourced software operator,which is the third management tier. The software operator can manage thesoftware operation from a control console, either located locally at thesmall business along with the computers being managed or alternativelyat some remote location, analogous to application operations managementconsole 242. The software operator then leases the computers back totheir owner, so the owner becomes the “user” of the computers, which isthe fourth management tier. During normal operation, the computer owneroccupies this fourth management tier. However, the computer owner canexercise its first management tier rights to sever one or both of theleases to the software operator and the hardware operator, such as whenthe computer owner desires to change software or hardware operators.

FIG. 5 is a block diagram illustrating an exemplary node in more detailin accordance with certain embodiments of the invention. Node 248 is anexemplary node managed by other devices (e.g., consoles 240 and 242 ofFIG. 3) external to the node. Node 248 can be a node 210 of FIG. 3, oralternatively a node at another location (e.g., a computer in a businessor home environment). Node 248 includes a monitor 250, referred to asthe “BMonitor”, and a plurality of software components or engines 252,and is coupled to (or alternatively incorporates) a mass storage device262. In the illustrated example, node 248 is a server computer having aprocessor(s) that supports multiple privilege levels (e.g., rings in anx86 architecture processor). In the illustrated example, these privilegelevels are referred to as rings, although alternate implementationsusing different processor architectures may use different nomenclature.The multiple rings provide a set of prioritized levels that software canexecute at, often including 4 levels (Rings 0, 1, 2, and 3). Ring 0 istypically referred to as the most privileged ring. Software processesexecuting in Ring 0 can typically access more features (e.g.,instructions) than processes executing in less privileged Rings.Furthermore, a processor executing in a particular Ring cannot altercode or data in a higher priority ring. In the illustrated example,BMonitor 250 executes in Ring 0, while engines 252 execute in Ring 1 (oralternatively Rings 2 and/or 3). Thus, the code or data of BMonitor 250(executing in Ring 0) cannot be altered directly by engines 252(executing in Ring 1). Rather, any such alterations would have to bemade by an engine 252 requesting BMonitor 250 to make the alteration(e.g., by sending a message to BMonitor 250, invoking a function ofBMonitor 250, etc.). Implementing BMonitor 250 in Ring 0 protectsBMonitor 250 from a rogue or malicious engine 252 that tries to bypassany restrictions imposed by BMonitor 250.

BMonitor 250 is the fundamental control module of node 248—it controls(and optionally includes) both the network interface card and the memorymanager. By controlling the network interface card (which may beseparate from BMonitor 250, or alternatively BMonitor 250 may beincorporated on the network interface card), BMonitor 250 can controldata received by and sent by node 248. By controlling the memorymanager, BMonitor 250 controls the allocation of memory to engines 252executing in node 248 and thus can assist in preventing rogue ormalicious engines from interfering with the operation of BMonitor 250.

Although various aspects of node 248 may be under control of BMonitor250 (e.g., the network interface card), BMonitor 250 still makes atleast part of such functionality available to engines 252 executing onthe node 248. BMonitor 250 provides an interface (e.g., via controller254 discussed in more detail below) 11 via which engines 252 can requestaccess to the functionality, such as to send data out to another node248 or to the Internet. These requests can take any of a variety offorms, such as sending messages, calling a function, etc.

BMonitor 250 includes controller 254, network interface 256, one or morefilters 258, and a Distributed Host Control Protocol (DHCP) module 260.Network interface 256 provides the interface between node 248 and thenetwork (e.g., network connections 126 of FIG. 3) via the internaltransport medium 211 of co-location facility 104. Filters 258 identifyother nodes 248 (and/or other sources or targets (e.g., coupled toInternet 108 of FIG. 1) that data can (or alternatively cannot) be sentto and/or received from. The nodes or other sources/targets can beidentified in any of a wide variety of manners, such as by networkaddress (e.g., Internet Protocol (IP) address), some other globallyunique identifier, a locally unique identifier (e.g., a numbering schemeproprietary or local to co-location facility 104), etc.

Filters 258 can fully restrict access to a node (e.g., no data can bereceived from or sent to the node), or partially restrict access to anode. Partial access restriction can take different forms. For example,a node may be restricted so that data can be received from the node butnot sent to the node (or vice versa). By way of another example, a nodemay be restricted so that only certain types of data (e.g.,communications in accordance with certain protocols, such as HTTP) canbe received from and/or sent to the node. Filtering based on particulartypes of data can be implemented in different manners, such as bycommunicating data in packets with header information that indicate thetype of data included in the packet.

Filters 258 can be added by application operations management console242 or cluster operations management console 240. In the illustratedexample, filters added by cluster operations management console 240 (toestablish cluster boundaries) restrict full access to nodes (e.g., anyaccess to another node can be prevented) whereas filters added byapplication operations management console 242 (to establishsub-boundaries within a cluster) can restrict either full access tonodes or partial access.

Controller 254 also imposes some restrictions on what filters can beadded to filters 258. In the illustrated example, controller 254 allowscluster operations management console 240 to add any filters it desires(which will define the boundaries of the cluster). However, controller254 restricts application operations management console 242 to addingonly filters that are at least as restrictive as those added by console240. If console 242 attempts to add a filter that is less restrictivethan those added by console 240 (in which case the sub-boundary mayextend beyond the cluster boundaries), controller 254 refuses to add thefilter (or alternatively may modify the filter so that it is not lessrestrictive). By imposing such a restriction, controller 254 can ensurethat the sub-boundaries established at the application operationsmanagement level do not extend beyond the cluster boundaries establishedat the cluster operations management level.

Controller 254, using one or more filters 258, operates to restrict datapackets sent from node 248 and/or received by node 248. All dataintended for an engine 252, or sent by an engine 252, to another node,is passed through network interface 256 and filters 258. Controller 254applies the filters 258 to the data, comparing the target of the data(e.g., typically identified in a header portion of a packet includingthe data) to acceptable (and/or restricted) nodes (and/or networkaddresses) identified in filters 258. If filters 258 indicate that thetarget of the data is acceptable, then controller 254 allows the data topass through to the target (either into node 248 or out from node 248).However, if filters 258 indicate that the target of the data is notacceptable, then controller 254 prevents the data from passing throughto the target. Controller 254 may return an indication to the source ofthe data that the data cannot be passed to the target, or may simplyignore or discard the data.

The application of filters 258 to the data by controller 254 allows theboundary restrictions of a server cluster to be imposed. Filters 258 canbe programmed (e.g., by application operations management console 242 ofFIG. 3) with the node addresses of all the nodes within the servercluster (e.g., cluster 212). Controller 254 then prevents data receivedfrom any node not within the server cluster from being passed through toan engine 252, and similarly prevents any data being sent to a nodeother than one within the server cluster from being sent. Similarly,data received from Internet 108 (FIG. 1) can identify a target node 210(e.g., by IP address), so that controller 254 of any node other than thetarget node will prevent the data from being passed through to an engine252.

DHCP module 260 implements the Distributed Host Control Protocol,allowing BMonitor 250 (and thus node 210) to obtain an IP address from aDHCP server (e.g., cluster operations management console 240 of FIG. 3).During an initialization process for node 210, DHCP module 260 requestsan IP address from the DHCP server, which in turn provides the IPaddress to module 260. Additional information regarding DHCP isavailable from Microsoft Corporation of Redmond, Wash.

Software engines 252 include any of a wide variety of conventionalsoftware components. Examples of engines 252 include an operating system(e.g., Windows NT®), a load balancing server component (e.g., to balancethe processing load of multiple nodes 248), a caching server component(e.g., to cache data and/or instructions from another node 248 orreceived via the Internet), a storage manager component (e.g., to managestorage of data from another node 248 or received via the Internet),etc. In one implementation, each of the engines 252 is a protocol-basedengine, communicating with BMonitor 250 and other engines 252 viamessages and/or function calls without requiring the engines 252 andBMonitor 250 to be written using the same programming language.

Controller 254 is further responsible for controlling the execution ofengines 252. This control can take different forms, including beginningexecution of an engine 252, terminating execution of an engine 252,re-loading an image of an engine 252 from a storage device, debuggingexecution of an engine 252, etc. Controller 254 receives instructionsfrom application operations management console 242 of FIG. 3 regardingwhich of these control actions to take and when to take them. Thus, thecontrol of engines 252 is actually managed by the remote applicationoperations management console 242, not locally at co-location facility104. Controller 254 also provides an interface via which applicationoperations management console 242 can identify filters to add (and/orremove) from filter set 258.

Controller 254 also includes an interface via which cluster operationsmanagement console 240 of FIG. 3 can communicate commands to controller254. Different types of hardware operation oriented commands can becommunicated to controller 254 by cluster operations management console240, such as re-booting the node, shutting down the node, placing thenode in a low-power state (e.g., in a 11 suspend or standby state),changing cluster boundaries, changing encryption keys, etc.

Controller 254 further provides encryption support for BMonitor 250,allowing data to be stored securely on mass storage device 262 (e.g., amagnetic disk, an optical disk, etc.) and secure communications to occurbetween node 248 and an operations management console (e.g., console 240or 242 of FIG. 3). Controller 254 maintains multiple encryption keys,including: one for the landlord (referred to as the “landlord key”)which accesses node 248 from cluster operations management console 240,one for the lessee of node 248 (referred to as the “tenant key”) whichaccesses node 248 from application operations management console 242,and keys that BMonitor 250 uses to securely store data on mass storagedevice 262 (referred to as the “disk key”).

BMonitor 250 makes use of public key cryptography to provide securecommunications between node 248 and the management consoles (e.g.,consoles 240 and 242). Public key cryptography is based on a key pair,including both a public key and a private key, and an encryptionalgorithm. The encryption algorithm can encrypt data based on the publickey such that it cannot be decrypted efficiently without the privatekey. Thus, communications from the public-key holder can be encryptedusing the public key, allowing only the private-key holder to decryptthe communications. Any of a variety of public key cryptographytechniques may be used, such as the well-known RSA (Rivest, Shamir, andAdelman) encryption technique. For a basic introduction of cryptography,the reader is directed to a text written by Bruce Schneier and entitled“Applied Cryptography: Protocols, Algorithms, and Source Code in C,”published by John Wiley & Sons with copyright 1994 (or second editionwith copyright 1996).

BMonitor 250 is initialized to include a public/private key pair forboth the landlord and the tenant. These key pairs can be generated byBMonitor 250, or alternatively by some other component and stored withinBMonitor 250 (with that other component being trusted to destroy itsknowledge of the key pair). As used herein, U refers to a public key andR refers to a private key. The public/private key pair 264 for thelandlord is referred to as (U_(L), R_(L)), and the public/private keypair 266 for the tenant is referred to as (U_(T), R_(T)). BMonitor 250makes the public keys U_(L) and U_(T) available to the landlord, butkeeps the private keys R_(L) and R_(T) secret. In the illustratedexample, BMonitor 250 never divulges the private keys R_(L) and R_(T),so both the landlord and the tenant can be assured that no entity otherthan the BMonitor 250 can decrypt information that they encrypt usingtheir public keys (e.g., via cluster operations management console 240and application operations management console 242 of FIG. 3,respectively).

Once the landlord has the public keys UL and UT, the landlord can assignnode 210 to a particular tenant, giving that tenant the public keyU_(T). Use of the public key U_(T) allows the tenant to encryptcommunications to BMonitor 250 that only BMonitor 250 can decrypt (usingthe private key R_(T)). Although not required, a prudent initial stepfor the tenant is to request that BMonitor 250 generate a newpublic/private key pair (U_(T), R_(T)). In response to such a request, akey generator 268 of BMonitor 250 generates a new public/private keypair in any of a variety of well-known manners, stores the new key pairas key pair 266, and returns the new public key U_(T) to the tenant. Bygenerating a new key pair, the tenant is assured that no other entity,including the landlord, is aware of the tenant public key U_(T).Additionally, the tenant may also have new key pairs generated atsubsequent times.

BMonitor 250 enforces restrictions on what entities can request newpublic/private key pairs. The tenant is able to request new tenantpublic/private key pairs, but is not able to request new landlordpublic/private key pairs. The landlord, however, can request newlandlord public/private key pairs as well as new tenant public/privatekey pairs. Whenever a request for a new public/private key pair isreceived, controller 254 verifies the identity of the requestor as thetenant or landlord (e.g., based on a remote log-in procedure, passwordverification, manner in which the requestor is communicating with or iscoupled to node 248, etc.) before generating the new key pair.

In order to ensure bi-directional communication security betweenBMonitor 250 and the landlord and tenant control devices (e.g.,operations management consoles 240 and 242, respectively), the landlordand tenant control devices may also generate (or otherwise be assigned)public/private key pairs. In this situation, consoles 240 and 242 cancommunicate their respective public keys to BMonitors 250 of nodes 248they desire (or expect to desire) to communicate with securely. Once thepublic key of a console is known by a BMonitor 250, the BMonitor 250 canencrypt communications to that console using its public key, therebypreventing any other device except the console having the private keyfrom reading the communication.

BMonitor 250 also maintains a disk key 270, which is generated based onone or more symmetric keys 272 and 274 (symmetric keys refer to secretkeys used in secret key cryptography). Disk key 270, also a symmetrickey, is used by BMonitor 250 to store information in mass storage device262. BMonitor 250 11 keeps disk key 270 secure, using it only to encryptdata node 248 stores on mass storage device 262 and decrypt data node248 retrieves from mass storage device 262 (thus there is no need forany other entities, including the landlord and tenant, to have knowledgeof disk key 270). Alternatively, the landlord or tenant may be informedof disk key 270, or another key on which disk key 270 is based.

Use of disk key 270 ensures that data stored on mass storage device 262can only be decrypted by the node 248 that encrypted it, and not anyother node or device. Thus, for example, if mass storage device 262 wereto be removed and attempts made to read the data on device 262, suchattempts would be unsuccessful. BMonitor 250 uses disk key 270 toencrypt data to be stored on mass storage device 262 regardless of thesource of the data. For example, the data may come from a client device(e.g., client 102 of FIG. 1) used by a customer of the tenant, from anoperations management console (e.g., console 242 of FIG. 3), etc.

Disk key 270 is generated based on symmetric keys 272 and 274. As usedherein, K refers to a symmetric key, so K_(L) refers to a landlordsymmetric key (key 272) and K_(T) refers to a tenant symmetric key (key274). The individual keys 272 and 274 can be generated in any of a widevariety of conventional manners (e.g., based on a random numbergenerator). Disk key 270 is either the K_(L) key alone, or alternativelyis a combination of the K_(L) and K_(T) keys. In situations where thenode 210 is not currently leased to a tenant, or in which the tenant hasnot established a K_(T) key, then controller 254 maintains the K_(L) keyas disk key 270. However, in situations where the node 248 is leased toa tenant that establishes a K_(T) key, then disk key 270 is acombination of the K_(L) and K_(T) keys. The K_(L) and K_(T) keys can becombined in a variety of different manners, and in one implementationare combined by using one of the keys to encrypt the other key, with theresultant encrypted key being disk key 270. Thus, the data stored onmass storage device 262 is always encrypted, even if the tenant does notestablish a symmetric key K_(T). Additionally, in situations where thelandlord and tenant are aware of their respective keys K_(L) and K_(T),then the combination of the keys results in a key that can be used toencrypt the data so that neither the landlord nor the tenant can decryptit individually.

In the illustrated example, a node 248 does not initially have symmetrickeys K_(L) and K_(T). When the landlord initializes the node 248, itrequests a new key K_(L) (e.g., via cluster operations managementconsole 240 of FIG. 3), in response to which key generator 268 generatesa new key and controller 254 maintains the newly generated key as key272. Similarly, when a tenant initially leases a node 248 there is notyet a tenant symmetric key K_(T) for node 248. The tenant cancommunicate a request for a new key K_(T) (e.g., via applicationoperations management console 242 of FIG. 3), in response to which keygenerator 268 generates a new key and controller 254 maintains the newlygenerated key as key 274. Additionally, each time a new key K_(T) orK_(L) is generated, then controller 254 generates a new disk key 270.

Although only a landlord and tenant key (K_(L) and K_(T)) areillustrated in FIG. 5, alternatively additional symmetric keys (e.g.,from a sub-tenant, a sub-landlord, etc.) may be combined to generatedisk key 270. For example, if there are three symmetric keys, then theycan be combined by encrypting a first of the keys with a second of thekeys, and then encrypting the result with the third of the keys togenerate disk key 270. Additional symmetric keys may be used, for 11example, for a sub-tenant(s).

The landlord can also request new public/private key pairs from BMonitor250, either tenant key pairs or landlord key pairs. Requesting new keypairs can allow, for example, the landlord to re-assign a node 248 fromone tenant to another. By way of example, if a tenant no longer desiresthe node 248 (or does not make required lease payments for the node),then the landlord can communicate with BMonitor 250 (e.g., via console240 of FIG. 3) to change the public/private key pairs of the tenant(thereby prohibiting any communications from the tenant from beingdecrypted by the BMonitor 250 because the tenant does not have the newkey). Additionally, the landlord may also request a new public/privatekey pair for the landlord—this may be done at particular intervals orsimply whenever the landlord desires a new key (e.g., for safetyconcerns).

In one implementation, BMonitor 250 discards both the disk key 270 andthe landlord symmetric key K_(L), and generates a new key K_(L) (and anew disk key 270) each time it generates a new landlord private keyR_(L). By replacing the key K_(L) and disk key 270 (and keeping norecord of the old keys), the landlord can ensure that once it changesits key, any tenant data previously stored at the node 210 cannot beaccessed. Thus, care should be taken by the landlord to generate a newpublic/private key pair only when the landlord wants to prevent thetenant from accessing the data previously stored at node 248.

Additionally, BMonitor 250 may also replace both the disk key 270 andthe tenant symmetric key K_(T), with a newly generated key K_(T) (and anew disk key 270) each time it generates a new tenant private key R_(T).This allows the tenant to increase the security of the data being storedat the node 248 because it can change how that data is encrypted as itdesires. However, as BMonitor 250 discards the previous key K_(T) anddisk key 270, care should be exercised by the tenant to request a newtenant private key R_(T) only when the data previously stored at node210 is no longer needed (e.g., has been backed up elsewhere).

It should be noted that different nodes 248 will typically havedifferent keys (keys 264, 266, and 270). Alternatively, attempts may bemade to have multiple nodes use the same key (e.g., key 270). However,in such situations care should be taken to ensure that any communicationof the keys (e.g., between nodes 248) is done in a secure manner so thatthe security is not compromised. For example, additional public/privatekey pairs may be used by BMonitors 250 of two nodes 248 to securelycommunicate information between one another.

A leased hardware environment having guaranteed and enforced rights canthus be established. Landlords can lease nodes to multiple differenttenants and establish boundaries that prevent nodes leased by differenttenants from communicating with one another. Tenants can be assured thatnodes they lease are accessible for management only to them, not toothers, and that data is stored at the nodes securely so that no oneelse can access it (even if the tenant leaves or reduces its hardwareusages). Furthermore, landlords and tenants are both assured that thelandlord can move equipment, change which nodes are assigned toindividuals, remove hardware (e.g., mass storage devices), etc. withoutcompromising the secure storage of data by any of the tenants.

FIG. 6 is a flowchart illustrating an exemplary process for encryptionkey generation and distribution in accordance with certain embodimentsof the invention. Initially, the computer (e.g., a node 248 of FIG. 5)identifies public/private key pairs for both the landlord and the tenant(act 280). This identification can be accessing previously generated keypairs, or alternatively 11 generating a new key pair by the computeritself. The computer keeps both the landlord private key from thelandlord key pair and the tenant private key from the tenant key pairsecret, but forwards the landlord public key from the landlord key pairand the tenant public key from the tenant key pair to the landlord (act282). In the illustrated example, the landlord is represented by clusteroperations management console 240 of FIG. 3, although alternativelyother devices or entities could represent the landlord.

The landlord then forwards the tenant public key to the tenant (act284). In the illustrated example, the tenant is represented byapplication operations management console 242 of FIG. 3, althoughalternatively other devices or entities could represent the tenant. Thetenant then communicates with the computer to generate a new tenant keypair (act 286). The computer keeps the tenant private key from the newkey pair secret and forwards the tenant public key from the new key pairto the tenant (act 288). The tenant is then able to communicate securemessages (e.g., data, instructions, requests, etc.) to the computerusing the new tenant public key (act 290), while the landlord is able tocommunicate secure messages to the computer using the landlord publickey (act 292).

FIG. 7 is a flowchart illustrating an exemplary process for theoperation of a cluster operations management console in accordance withcertain embodiments of the invention. The process of FIG. 7 isimplemented by a cluster operations management console at a co-locationfacility, and may be performed in software.

Initially, the cluster operations management console configures thenodes in the server cluster with the boundaries (if any) of the servercluster (act 300). This configuration is accomplished by the clusteroperations management console communicating filters to the nodes in theserver cluster(s).

Hardware operations within a server cluster are then continuallymonitored for a hardware failure (acts 302 and 304). Once a hardwarefailure is detected, corrective action is taken (act 306) and monitoringof the hardware operation continues. Any of a wide variety of correctiveaction can be taken, as discussed above. Note that, based on thecorrective action (or at other times), the nodes may be re-configuredwith new cluster boundaries (act 300).

FIG. 8 is a flowchart illustrating an exemplary process for theoperation of an application operations management console in accordancewith certain embodiments of the invention. The process of FIG. 8 isimplemented by an application operations management console locatedremotely from the co-location facility, and may be performed insoftware.

Initially, the application operations management console configures thenodes in the server cluster with sub-boundaries (if any) of the servercluster (act 320). This configuration is accomplished by the applicationoperations management console communicating filters to the nodes in theserver cluster.

Software operations within the server cluster are then continuallymonitored until a software failure is detected (acts 322 and 324). Thissoftware failure could be failure of a particular software engine (e.g.,the engine fails, but the other engines are still running), oralternatively failure of the entire node (e.g., the entire node ishung). Once a software failure is detected, corrective action is taken(act 326) and monitoring of the software operation continues. Any of awide variety of corrective action can be taken, as discussed above. Notethat, based on the corrective action (or at any other time duringoperation), the server computer may be re-configured with newsub-boundaries (act 320).

Conclusion

Although the description above uses language that is specific tostructural features and/or methodological acts, it is to be understoodthat the invention defined in the appended claims is not limited to thespecific features or acts described. Rather, the specific features andacts are disclosed as exemplary forms of implementing the invention.

1. A method comprising: allowing a tenant to which a cluster of one ormore computers at a facility have been leased to communicate with theone or more computers; and implementing cluster boundaries at thefacility to prevent computers within the cluster from communicating anydata with computers in another cluster.
 2. A method as recited in claim1, wherein the facility comprises a co-location facility.
 3. A method asrecited in claim 1, wherein the allowing comprises establishing securecommunications channels between the one or more computers and acorresponding tenant operations management console.
 4. A method asrecited in claim 1, wherein the implementing cluster boundariescomprises adding one or more filters to each of the one or morecomputers in the cluster.
 5. A method as recited in claim 4, wherein theimplementing cluster boundaries further comprises including, in filtersof each of the one or more computers, the addresses of the othercomputers at the facility that are not in the cluster.
 6. A method asrecited in claim 4, further comprising: allowing the tenant to establishsub-boundaries within the cluster to prevent one or more computers inthe cluster from communicating with one or more other computers in thecluster.
 7. A method as recited in claim 6, wherein allowing the tenantto establish sub-boundaries comprises allowing the tenant to add one ormore additional filters to one or more computers in the cluster, whereineach of the one or more additional filters is at least as restrictive asthe one or more filters added in implementing the cluster boundaries. 8.A computer comprising: a controller including an interface via which atenant to which a cluster of computers at a facility have been leasedcan communicate with the computer, wherein the computer is included inthe cluster; a plurality of filters, each filter restrictingcommunication with one or more other computers at the facility; andwherein the controller uses the plurality of filters to implement acluster boundary at the facility to prevent all data communicationsbetween the computer and other computers in other clusters.
 9. Acomputer as recited in claim 8, wherein one of the plurality of filtersindicates that no data can be sent to a particular one or more of theother computers.
 10. A computer as recited in claim 8, wherein one ofthe plurality of filters indicates that no data can be received from aparticular one or more of the other computers.
 11. A computer as recitedin claim 8, wherein each of the plurality of filters includes an addressof one of the other computers in one of the other clusters.
 12. Acomputer as recited in claim 8, further comprising: one or moreadditional filters, each of the one or more additional filtersrestricting communication with one or more computers in the cluster ofcomputers; and wherein the controller uses the one or more additionalfilters to implement a sub-boundary within the cluster of computers toprevent the computer from communicating with one or more additionalcomputers in the cluster.
 13. A computer as recited in claim 12, whereineach of the one or more additional filters is at least as restrictive asthe plurality of filters.
 14. One or more computer-readable media havingstored thereon instructions that, when executed by one or moreprocessors, cause the one or more processors to: allow a tenant to whicha cluster of one or more computers at a facility have been leased tocommunicate with the one or more computers; and implement clusterboundaries at the facility to prevent all data communications betweencomputers within the cluster and computers in another cluster.
 15. Oneor more computer-readable media as recited in claim 14, wherein theinstructions further cause the one or more processors to: perform atleast some management of the computers via a landlord operationsmanagement console; and establish secure communications channels betweeneach of the plurality of computers and the landlord operationsmanagement console.
 16. One or more computer-readable media as recitedin claim 15, wherein the landlord operations management console islocated at the facility.
 17. One or more computer-readable media asrecited in claim 14, wherein to implement cluster boundaries is to addone or more filters to each of the one or more computers in the cluster.18. One or more computer-readable media as recited in claim 17, whereinto implement cluster boundaries is further to include, in filters ofeach of the one or more computers, the addresses of the other computersat the facility that are not in the cluster.
 19. One or morecomputer-readable media as recited in claim 17, wherein the instructionsfurther cause the one or more processors to: allow the tenant toestablish sub-boundaries within the cluster to prevent one or morecomputers in the cluster from communicating with one or more othercomputers in the cluster.
 20. One or more computer-readable media asrecited in claim 19, wherein to allow the tenant to establishsub-boundaries is to allow the tenant to add one or more additionalfilters to one or more computers in the cluster, wherein each of the oneor more additional filters is at least as restrictive as the one or morefilters added in implementing the cluster boundaries.